1. Technical Field
The embodiment of the invention relates generally to data processing and particularly to monitoring code sensitivity to cause software build breaks during software project development.
2. Description of the Related Art
When teams of developers work together on a software project to develop a software project, the developers access software build files for the software project, edit the software build files, and commit the edited files to a software build. Each developer may access software build files from a source control system that manages a repository for the software build, tracks the developer changes to the files in the software build, and manages commitment of the edited files to the software build.
When developers edit files and commit the files to the software build, developers often include defects in the edited files that will cause the software build to fail when executed, also referred to as breaking the software build. When large software projects are developed, with many files in the software build, along with multiple developers accessing and editing the many files, it may be difficult to keep track of which files, when changed, cause the software build to break and time may be wasted as developers, through trial and errors, submit edited files that break the software build. A developer learning about the likelihood that edits to a file will break the software build, through trial and error and testing, requires development time and does not provide other developers with this learned understanding that edits to a file are likely to cause a build to break. The developer's rate of gaining an understanding of the importance of the file is also limited by the developer's experience editing a particular software project build and the developer's overall experience level editing code. Moreover, the likelihood that edits to a file to may cause breaks in a software build may be further impacted by the experience level of the developer editing the file, where a developer with less programming experience with a particular type of code function may introduce more errors into a file that cause the file to break the software build than would a developer with more programming experience with the particular type of code function.
A source control system that manages a repository may include a GIT function that tracks metrics of the number of lines of code changed in a file committed to the software build and the number of times a file is committed. Developers may access a GIT report prepared by the GIT function to receive a log of the metrics, which provides some information about the potential importance of a file, however, the number of lines changed in a file and the number of times a file is committed alone does not provide developers with a full understanding of the likelihood that a file may cause breaks in a particular software build because some software builds may have files that are heavily edited, but do not cause the build to break and other software build may have files where a single line edit in the file may cause the software build to break. In addition, the GIT function metrics do not provide any information about the relative experience level of the developer editing the file, however, the relative experience level of the developer editing the file may impact the number of lines the developer edits and the number of times the files is committed with changes. In addition, relying on a developer to interpret the results of the GIT report increases development time and interpretations of the results may vary based on the developer's experience with editing a particular software project build and the developer's overall experience level editing code.
US Publication 20150143335 to Jain et al. describes another tool provided at a source control system that performs steps of analyzing the source code itself and collecting, for a particular file, “code coverage information” comprising “complexity of code, line and branch coverage, “source code violation information” comprising “common programming mistakes and bugs . . . like unused variables, unnecessary object creation, possible null pointer exceptions, dead code, duplicate codes and overcomplicated expressions” identified by a “source code analyzer module 102” searching the source code contents and identifying common bugs, and “source code commit information comprising a committed information of plurality of files within specific time period, a user information of committed plurality of files, a revision change information of lines for each of the plurality of files and a defect information of committed plurality of files.” US Publication 20150143335 collects the “code coverage information”, “source code violation information”, and “source code commit information” for a particular file and publishes the log of information for the particular file in a report. However, Jain et al.'s log of additional information collected about a particular file committed to source code, collected from the contents of that source code alone, does not provide developers with a full understanding of the sensitivity of a file to cause breaks in a particular software build, where some software builds may have files that are heavily edited, but do not cause the build to break and other software build may have files where a single line edit in the file may cause the software build to break. In addition, Jain's log of additional information about a particular file committed to source code does not provide developers with a real-time analysis and assessment of the sensitivity, of a file that causes a break to a particular software build, to cause further breaks in the software build. In addition, US Publication 20150143335 is limited to collecting information about the contents of the source code committed, which does not provide any information about the relative experience level of the developer editing the file, which impacts the contents of the particular file committed.
As the speed of software development continues to accelerate and development teams change from one software project to another software project, there is a need for a method, system and computer program product for supporting software development within software development build environments that minimizes the development time required for identification and mitigation of defects in sections of code of the software build. In addition, as the number of developers on project build teams increases, to efficiently manage the team and minimize redundant errors in files that are more sensitive to cause breaks to the build, there is a need for a method, system, and computer program product for logging more than the contents of the files at the commit level at the source code server.